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                    Reliable Server Pooling Policies

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This document describes server pool policies for Reliable Server
   Pooling (RSerPool) including considerations for implementing them at
   Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool
   users.
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1.  Introduction

   The protocols defined in [RFC5353], [RFC5352], and [RFC5354] support
   a variety of server policies.  Some of the policies use dynamic load
   information of the pool elements and others do not.  Therefore, we
   classify them as adaptive and non-adaptive.  The selection of the
   pool element is performed by two different entities, the ENRP server
   and the pool user.  Some of the consequences for policies that are
   not stateless are described in [ICN2005] and [LCN2005].

   Therefore, this document describes not only packet formats but also
   gives a detailed description of the procedures to be followed at the
   ENRP servers and the pool users to implement each server policy.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology and Definitions

3.1.  Load

   The term load is a value specifying how much a pool element's
   resources are currently utilized. 0x00000000 states that the pool
   element is not utilized (0%); 0xffffffff states that it is fully
   utilized (100%).  Defining what utilization means is application-
   dependent and out of the scope of RSerPool.  However, it is required
   that all pool elements of the same pool using load information have
   the same definition of load.

   For example, load may define the current amount of users out of a
   maximum on an FTP server, the CPU usage of a database server, or the
   memory utilization of a compute service.

3.2.  Weight

   Weight defines a pool element's service capacity relative to other
   pool elements of the same pool.  Theoretically, there is no upper
   limit for weight values (although limited by datatype size).
   Defining what value weights compare is application-dependent and out
   of the scope of RSerPool.  However, it is required that all pool
   elements of the same pool using weight information have the same
   definition of weight.
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   A weight of 0 denotes that the pool element is not capable of
   providing any service; a higher weight denotes that the pool element
   is capable of providing better service than a pool element having a
   lower weight.

   For example, weight may define a compute service's computation
   capacity.  That is, a pool element of weight 100 will complete a work
   package in half the time compared to a pool element of weight 50.

4.  Non-Adaptive Policies

4.1.  Round Robin Policy

4.1.1.  Description

   The Round Robin (RR) policy is a very simple and efficient policy
   that requires state.  This policy is denoted as the default policy
   and MUST be supported by all RSerPool components.

4.1.2.  ENRP Server Considerations

   The ENRP server SHOULD hold the pool elements of each server pool in
   a circular list and SHOULD store a pointer to one of the elements,
   called the head.  On reception of a handle resolution request, the
   ENRP server SHOULD return the pool elements from the circular list,
   starting with head.  Then the head SHOULD be advanced by one element.

   Using this algorithm ensures that not all lists presented to the pool
   users start with the same element.

4.1.3.  Pool User Considerations

   A pool user SHOULD use the list of pool elements returned by the ENRP
   server in a round robin fashion, starting with the first.  If all
   elements of the list have been used, it should start from the
   beginning again until the information is out of date.

4.1.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0x8          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x00000001                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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4.2.  Weighted Round Robin Policy

4.2.1.  Description

   The Weighted Round Robin (WRR) policy is a generalization of the RR
   policy.  If all weights are 1, then WRR is just RR.

4.2.2.  ENRP Server Considerations

   The ENRP server SHOULD follow the same rules as RR but initialize and
   modify the circular list differently.  The ENRP server puts each pool
   element, possibly, multiple times into the list such that:

   o  The ratio of the number of occurrences of a pool element to the
      list length is the same as the ratio of the weight of that pool
      element to the sum of weights.

   o  The multiple entries of each pool element should be as evenly
      distributed as possible in the circular list.

4.2.3.  Pool User Considerations

   The pool user SHOULD follow the same rules as RR.

4.2.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0xc          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x00000002                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Weight                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Weight (32 bits, unsigned integer): Weight constant for the WRR
      process.

4.3.  Random Policy

4.3.1.  Description

   The Random (RAND) policy is a very simple stateless policy.
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4.3.2.  ENRP Server Considerations

   The ENRP server selects, at most, the requested number of pool
   elements from the list of pool elements.  Each element MUST NOT be
   reported more than once to the pool user.

4.3.3.  Pool User Considerations

   Each time the pool user must select one pool element, it does this by
   randomly selecting one element from the list of pool elements
   received from the ENRP server.

4.3.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0x8          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x00000003                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.  Weighted Random Policy

4.4.1.  Description

   The Weighted Random (WRAND) policy is a generalization of the RAND
   policy, adding a weight for each pool element entry.  RAND is equal
   to WRAND having all weights set to 1.

4.4.2.  ENRP Server Considerations

   The ENRP server SHOULD select, at most, the requested number of pool
   elements randomly from the list of pool elements.  Each element MUST
   NOT be reported more than once to the pool user.  The probability of
   selecting a pool element should be the ratio of the weight of that
   pool element to the sum of weights.

4.4.3.  Pool User Considerations

   Each time the pool user must select one pool element, it does this by
   randomly selecting one element from the list of pool elements
   received from the ENRP server.
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4.4.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0xc          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x00000004                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Weight                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Weight (32 bits, unsigned integer): Weight constant for the WRAND
      process.

4.5.  Priority Policy

4.5.1.  Description

   The Priority (PRIO) policy can be used to select always a pool
   element with the highest priority.

4.5.2.  ENRP Server Considerations

   The ENRP server MUST select the pool elements with the highest
   priorities.  They MUST be reported in decreasing order.  If multiple
   pool elements have the same priority, they may be listed in any
   order.

4.5.3.  Pool Element Considerations

   The pool user MUST select the active pool element with the highest
   priority.

4.5.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0xc          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x00000005                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Priority                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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   o  Priority (32 bits, unsigned integer): Larger numbers mean higher
      priorities.

5.  Adaptive Policies

5.1.  Least Used Policy

5.1.1.  Description

   The Least Used (LU) policy uses load information provided by the pool
   elements to select the lowest-loaded pool elements within the pool.

5.1.2.  ENRP Server Considerations

   The ENRP server SHOULD select, at most, the requested number of pool
   elements.  Their load values SHOULD be the lowest possible ones
   within the pool.  Each element MUST NOT be reported more than once to
   the pool user.  If there is a choice of equal-loaded pool elements,
   round robin selection SHOULD be made among these elements.  The
   returned list of pool elements MUST be sorted in ascending order by
   load value.

5.1.3.  Pool User Considerations

   The pool user should try to use the pool elements returned from the
   list in the order returned by the ENRP server.  A subsequent call for
   handle resolution may result in the same list.  Therefore, it is
   RECOMMENDED for a pool user to request multiple entries in order to
   have a sufficient amount of feasible backup entries available.

5.1.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0xc          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x40000001                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Load                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Load (32 bits, unsigned integer): Current load of the pool
      element.
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5.2.  Least Used with Degradation Policy

5.2.1.  Description

   The Least Used with Degradation (LUD) policy extends the LU policy by
   a load degradation value describing the pool element's load increment
   when a new service association is accepted.

5.2.2.  ENRP Server Considerations

   For every pool element entry, a degradation counter MUST be stored.
   When a pool element entry is added or updated by registration or re-
   registration, this counter MUST be set to 0.  When an entry is
   selected for being returned to a pool user, the internal degradation
   counter MUST be incremented by 1.  The selection of pool element
   entries is handled like for LU, except that the selected pool element
   entries SHOULD have the lowest possible sum of load value +
   degradation counter * load degradation value.

5.2.3.  Pool User Considerations

   See LU policy.

5.2.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0x10         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x40000002                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Load                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Load Degradation                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Load (32 bits, unsigned integer): Current load of the pool
      element.

   o  Load Degradation (32 bits, unsigned integer): Load Degradation
      constant of the pool element.
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5.3.  Priority Least Used Policy

5.3.1.  Description

   The Priority Least Used (PLU) policy uses load information provided
   by the pool elements to select the lowest-loaded pool elements within
   the pool under the assumption that a new application request is
   accepted by the pool elements.  Therefore, the pool elements also
   have to specify load degradation information.

   Example: Pool elements A and B are loaded by 50%, but the load of A
   will increase due to a new application request only by 10% while B
   will be fully loaded.  PLU allows the specification of this load
   degradation in the policy information; the selection is made on the
   lowest sum of load and degradation value.  That is, A will be
   selected (50+10=60) instead of B (50+50=100).

5.3.2.  ENRP Server Considerations

   The ENRP server SHOULD select, at most, the requested number of pool
   elements.  Their sums of load + degradation SHOULD be the lowest
   possible ones within the pool.  Each element MUST NOT be reported
   more than once to the pool user.  If there is a choice of equal-
   valued pool element entries, round robin SHOULD be made among these
   elements.  The returned list of pool elements MUST be sorted
   ascending by the sum of load and degradation value.

5.3.3.  Pool User Considerations

   The pool user should try to use the pool elements returned from the
   list in the order returned by the ENRP server.  A subsequent call for
   handle resolution may result in the same list.  Therefore, it is
   RECOMMENDED for a pool user to request multiple entries in order to
   have a sufficient amount of feasible backup entries available.

5.3.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0x10         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x40000003                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Load                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Load Degradation                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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   o  Load (32 bits, unsigned integer): Current load of the pool
      element.

   o  Load Degradation (32 bits, unsigned integer): Load Degradation
      constant of the pool element.

5.4.  Randomized Least Used Policy

5.4.1.  Description

   The Randomized Least Used (RLU) policy combines LU and WRAND.  That
   is, the pool element entries are selected randomly.  The probability
   for a pool element entry A, utilized with load_A, to be selected is
   (0xFFFFFFFF - load_A) / (sum(0xFFFFFFFF-load_x)), i.e., this PE's
   unload part related to the whole pool unload rate.

5.4.2.  ENRP Server Considerations

   The ENRP server SHOULD behave like WRAND, having every PE's weight
   set to (0xffffffff -- load value provided by the pool element).

5.4.3.  Pool User Considerations

   See WRAND policy.

5.4.4.  Pool Member Selection Policy Parameter

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Param Type = 0x8           |         Length = 0xc          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Policy Type = 0x40000004                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Load                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Load (32 bits, unsigned integer): Current load of the pool
      element.

6.  Security Considerations

   The security threats regarding RSerPool have been analyzed in
   RSerPool threats [RFC5355].  The server policy descriptions in this
   document do not add any other threats.
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7.  IANA Considerations

   This document (RFC 5356) is the reference for all registrations
   described in this section.  All registrations have been listed on the
   RSerPool Parameters page.

7.1.  A New Table for RSerPool Policy Types

   RSerPool policy types that are 4-byte values are maintained by IANA.
   The format of the policy type value is defined as follows:

         0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |X|A|                   Policy Number                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  X: If set to 1, the policy is user defined and not standardized.
      All standards policies reserved by the IETF use X=0.

   o  A: If set to 1, the policy is adaptive.  Otherwise, it is non-
      adaptive.

   o  Policy Number: The actual number of the policy.

   Nine initial policy types have been assigned and are maintained in a
   new table, "RSerPool Policy Types":
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     Value           Policy                                  Reference
     -----           ---------                               ---------
     0x00000000      (reserved, invalid value)               RFC 5356
     0x00000001      Round Robin                             RFC 5356
     0x00000002      Weighted Round Robin                    RFC 5356
     0x00000003      Random                                  RFC 5356
     0x00000004      Weighted Random                         RFC 5356
     0x00000005      Priority                                RFC 5356
     0x00000006      (reserved by IETF)                      RFC 5356
     ...
     0x3fffffff      (reserved by IETF)                      RFC 5356

     0x40000000      (reserved, invalid value)               RFC 5356
     0x40000001      Least Used                              RFC 5356
     0x40000002      Least Used with Degradation             RFC 5356
     0x40000003      Priority Least Used                     RFC 5356
     0x40000004      Randomized Least Used                   RFC 5356
     0x40000005      (reserved by IETF)                      RFC 5356
     ...
     0x7fffffff      (reserved by IETF)                      RFC 5356

     0x80000000      (private use, non-standard policy)      RFC 5356
     ...
     0xffffffff      (private use, non-standard policy)      RFC 5356

   Requests to register an RSerPool policy type in this table should be
   sent to IANA.  The number must be unique and use the appropriate
   upper bits.  The "Specification Required" policy of [RFC5226] MUST be
   applied.

   The policy type space from 0x80000000 to 0xffffffff is designated for
   private use.

8.  Reference Implementation

   A reference implementation of RSerPool and the policies described in
   this document is available at [RSerPoolPage] and described in
   [Dre2006].
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